-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schemas v0.1 v0.2 #76
Conversation
That last commit avoids the need to run
|
The last commit uses a better approach of subclassing the RefResolver to always load local schemas instead of remote. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In general, love all the examples and the fact that this covers all current versions. One general naming consideration about the URLs since those are something we want to last. I haven't (yet) gone through each example and schema, but I don't think I'll get to that before Thursday. If it helps to get this in here so that ome-zarr-py etc. can build on top of it, no objections. We should just review before we make the URLs live. (I assume at this point they don't actually get built into the spec page)
@@ -2,7 +2,6 @@ | |||
"@type": "ngff:Image", | |||
"multiscales": [ | |||
{ | |||
"version": "0.2", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was dropped from v0.3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed to "0.1"
0.3/schemas/json_schema/image.schema
Outdated
@@ -1,6 +1,6 @@ | |||
{ | |||
"$schema": "https://json-schema.org/draft/2020-12/schema", | |||
"$id": "http://localhost:8000/image.schema", | |||
"$id": "https://ngff.openmicroscopy.org/0.3/schemas/json_schema/image.schema", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The "schema(s)" in this URL are a bit much....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is just the path we currently have in this repo. Since we're only supporting json_schema
now, we could drop that dir. But the paths are even more painful at ome/ome-zarr-py#142 where I wanted to maintain the same directory structure as here, simply replacing https://ngff.openmicroscopy.org/
with a single path in that repo (expecting that we'll package the schemas as part of the release). So the path in that repo then becomes schemas/0.3/schemas/json_schema/image.schema
!
The problem with is that in the NGFF repo, the version is at the top level, so we have a schemas
directory under each version, but it's the other way around on ome-zarr-py
where I wanted all the schemas to be under a top-level schemas/
.
Need to unify the approach between the repos. Do we create top-level version dirs on ome-zarr-py
?
Once we've "published" a schema to a public URL that people can use for validation, can we make any future changes to that schema, and how do we version it? |
From the discussion this morning a plan of action:
I think only the first point should be done in this PR? |
Merging as discussed this morning. As mentioned, we can re-review the URLs before going public with them. |
Schemas v0.1 v0.2 SHA: a20dd71 Reason: push, by @joshmoore Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This adds schemas, tests and samples for JSON schema support of v0.1 and v0.2.
Updates all schemas to NOT require version, name etc, since these are only
SHOULD
in the spec (noticed this when validating some existing v0.1 files).Also adds plate samples and plate.schema for the HCS spec (tests for 0.1 only, since this hasn't changed since).
This also adds a way of specifying the
SHOULD
rules within the schema, using a second schema withallOf
to add restrictions to theimage.schema
(see below - thanks @sbesson).This more strict schema can be used to validate without failing on the first Error, allowing it to be used for reporting multiple suggestions for rules that
SHOULD
be obeyed, but aren't actually invalid.Added tests that check that all valid files (except
image_complete.json
) give at least oneSHOULD
warning.